An Overview of Information Modeling for Manufacturing Systems Integration

ion Construct None Abstract Supertype Abstract Class, Abstract Operation 4. INFORMATION MODEL DEVELOPMENT PROCESS This section describes the process for developing a “quality” information model. A “quality” information model (for the scope intended) is that the model is complete, sharable, stable, extensible, well-structured, precise, and unambiguous. In general, the contents of an information model include a scope, information requirements, and a specification. The detailed explanations of each area are given in the following paragraphs. The initial phase for developing an information model starts with the definition of the scope of the model's applicability. The scope specifies the domain of discourse and the processes that are to be supported by the information model. It is a bounded collection of processes, information, and constraints that satisfy some industry need. The scope statements include the purpose as well as viewpoints of the model, the type of product, the type of data requirements, the supporting manufacturing scenario, the supporting manufacturing activities, and the supporting stage in the product life cycle. The scope definition may be supported by an activity model and/or a data planning model. An activity model is a representation of the application context, data flows, and the processes of the application. It is a mechanism for gathering high level information requirements. A data planning model provides a high level description of the data requirements for the information model, as well as the relationships among the basic data components. It is used as a roadmap to establish interfaces across a wide range of data. A well-defined scope should be accurate, unambiguous, viable, and meet the industrial need. During the course of the modeling, the scope should be revisited and may be refined. Since the scope provides the boundaries of the application domain, it also serves as a guildine for evaluating the “completeness” of the information model. After the scope is defined, the next phase is to conduct a requirements analysis. There is no standard method for collecting information requirements. However, requirements analysis may be accomplished by: literature surveys, standards surveys, domain experts’ interviews, industrial data reviews, and state-of-the-art assessments. Depending on the scope, the analysis may include today's manufacturing practices, traditional practices, and near-future needs. It is important to capture data requirements accurately for the application scope while performing the requirements analysis. Industry reviews of the result of the analysis will help to ensure the completeness and correctness of the information requirements. As the result of the requirements analysis, information requirements should be documented. The definition of each identified information item should be included in the document. This document will be a strawman for developing the information model. After the detailed scope and information requirements are defined, the next phase is to develop the model. This phase transforms information requirements into a conceptual model. The information model is independent of any physical implementation, and it should be developed using a formal modeling language. Each information requirement should be expressed in the model. The model should be sufficiently detailed to describe the data needs of the application fully. To actually develop the information model, three types of design approaches can be taken: a top-down design, a bottom-up design, and a mixed or inside-out design. While the most effective way is to take the top-down design approach for modeling, it may not be possible or appropriate in all cases. An optimal design approach may depend on the individual application environment. Conceptualizing information requirements starts with grouping concepts, that is, to identify the model's units of functionality. After that, an abstraction process will be performed to establish the model's structure for each functionality. This abstraction process, which structures information requirements into entities, objects, or classes, may include generalization, specialization, aggregation, classification, and association. Classification is the grouping of objects with the same data structure and operation. Generalization, specialization, aggregation, and association are for establishing relationships among the model’s elements. Generalization and specialization identify the “inheritance-from” and “inheritance-to” relationships, respectively. Aggregation identifies “subset-of” relationships. Association identifies “dependency” relationships. Once the structure of the model is established, it must then be laid out according to the syntax of the selected modeling language. 5. IMPLEMENTATION METHODS AND ISSUES An information model provides a sharable, stable, and organized structure of information requirements. It is developed to preserve independence from both usage and implementation. Implementation independence allows users to select their implementation methods. Three types of implementation methods are currently used by the manufacturing community: 1) Data transfer via a working form, which is a structured, in-memory representation of data, 2) Data transfer via an exchange file, which is a file with a predefined structure or format, and 3) Data transfer using a database management system. These implementation methods can be accomplished through programming languages and DBMSs. Method 1 uses the mechanism that accesses and changes data without actually moving the data around. All shared data are stored in memory. Method 2 requires a neutral file format for storing the data. The application systems read and write from files. Method 3 uses a DBMS where information is mapped onto and retrieved from databases. DBMSs' access methods generally use either libraries of routines or embedded data access/manipulation languages. The types of DBMSs used include O-O DBMSs and relational DBMSs. The selection of an implementation method is heavily dependent on the target environment where the application system resides. While the relational DBMS is generally desirable for data access, the traditional file-oriented systems are being used continually by many manufacturing applications. An O-O model is more easily implemented using an O-O language or an O-O DBMS; however, it can also be implemented using a conventional programming language or a relational DBMS [14]. A few lessons learned are described here. 1) Information requirements serve as the foundation of the model. A thorough requirements analysis is a necessity. Literature surveys, standard surveys, domain experts interviews, industrial data reviews, and state-of-the-art assessments are a source of capturing knowledge. Workshops are a good way to gather requirements and to reach a consensus on the requirements. 2) Modeling is an iterative process, as refinements are often necessary. As iteration continues, the information model obtained at the end of each iteration is presented to the user community to obtain further feedback. 3) It is useful to establish a set of naming conventions for a big and complex model in the beginning of the modeling effort. The naming conventions should be descriptive in nature. Advantages for using naming conventions are: consistency, ease of identifying entities, and ease of collaboration. 4) Developing a glossary of terms that are used by the applications is also useful. The purpose of the glossary is to provide a unique definition for each term to eliminate improper use due to conflicting definitions. Sometimes the same terms may have different meanings or different terms may have the same meaning. The glossary that precisely defines all terms presented with the information model is an effective solution to this problem. 5) There are several common problems during the implementation process. The most fundamental effort is that if a particular information model serves as the medium for transferring the data, the application system should be brought in to some degree of compliance with this information model. Occasionally, there is no complete data mapping between the model and the system. This may be due to the fact that data requirements are not a complete set, or some private data from certain application systems are not intended to be shared. If the data requirements are not complete, further requirements analysis should be conducted. For proprietary data, implementation-specific arrangements should be made. 6) Using different measurement units is another common error in an implementation. This can be avoided by including the measurement unit(s) to the information model. 7) Conflicts in precision is another issue. The information model should declare the specified precision for numeric data. If the application system carries a lower precision, the accuracy may be lost. 8) Finally, having industry reviews of the information model is critical. It helps to ensure the model's necessity, correctness, and completeness for the business need for which it was developed. 6. EXAMPLE OF AN INFORMATION MODELING EFFORT This section describes how a real-life information model, Pattern Information Model [13], was developed. The information model was developed to support the Defense Logistics Agency’s apparel research program in the area of electronic commerce. The model is for the exchange of two-dimensional apparel patterns between different CAD systems and between the pattern design process and other apparel life cycle processes. The development of the model was an integrated effort from several tasks: 1) File format evaluation: In the late 1980s, the American Apparel Manufacturers Association (AAMA) took the position that the apparel industry urgently needed a mechanism for automatic transfer of pattern data and hence asked NIST and the Apparel CIM Center of the University of Southwestern Louisiana to develop a neutral data format for the representation of 2-D pattern pieces for the apparel industry. As a result, it was recommended that the AutoDesk DXF format [16] be used as the framework to develop a near-term, neutral format for pattern data. In addition, it was recommended that a STEP application model of apparel patterns be developed for the apparel industry as a long-term strategy [17]. 2) Glossary development: A study on apparel manufacturing terms, especially those used in the pattern-making process, wasperformed at NIST. As a result, a working set of terms and definitions from published literature was created to act as acatalyst in the development of a consensus glossary [18]. 3) Requirements analysis: A task to identify information requirements for apparel pattern making was performed at NIST.Efforts included visiting and consulting with apparel manufacturers, the Defense Support Center Philadelphia, independentapparel research laboratories, traditional dressmakers, and tailors; reviewing existing standards; studying industrial data;and actively participating in activities held by the Apparel Research Committee of AAMA and the DLA Apparel ResearchNetwork. As a result, an activity model of pattern making was developed [15], and a preliminary set of data requirementswas identified [13]. In addition, “A Survey of Standards for the U.S. Fiber/Textile/Apparel Industry” [19], “A Bibliographyon Apparel Sizing and Related Issues” [20], and “Body Dimensions for Apparel” [21] were published. 4) Model layout: Mapping the data requirements to an EXPRESS model was the next step. The schema presented in [13]was developed through three major iterations. The experience gained through the implementation of the prototypeinformation model and recommendations received from apparel researchers provided useful inputs for improving the earlyversions of the model. A prototype of the current model has been demonstrated using two military garments. The modelnow can be used as the initial proposal for developing an official specification. It can also be extended to include all theinformation necessary for an apparel product throughout its development life cycle. 7. SCOPING THE MANUFACTURING ENTERPRISETo support the manufacturing system integration, it is important to identify types of manufacturing information that areneeded to be shared or exchanged. This section specifies a possible set of manufacturing data interfaces that could bemodeled and standardized for the effective computer integration of the information required to operate today’smanufacturing enterprise. The scoping of the manufacturing enterprise is based on the activity IDEF0 model [22],developed by NIST’s SIMA project, in which the generic activities in a manufacturing, and information flows required tosupport those activities are presented. The viewpoint of the SIMA Manufacturing Activity Model is that of the engineeringor production manager responsible for assigning the engineering or production tasks and ensuring that the results of onetask are provided to another. The model covers three functions: design engineering, manufacturing and production systemsengineering , and production; the activities identified in the model are supported by existing (off-the-shelf) softwaresystems.Table 2 lists manufacturing data interfaces, the activities supported by each data interface, and the informationrequirements provided by each data interface. In most cases, the activities and information requirements of Table 2 describethe top-level interfaces only, i.e., they are most likely defined in the primary decomposition (A1, A2, A3, A4, and A5) ofthe highest-level activity (A0) of the SIMA Manufacturing Activity Model. Some information requirements may come fromsubsequent decomposition of the refinement activities. Table 2. Types of Data Interfaces that Support Manufacturing Systems Integration Data InterfaceActivities SupportedInformation RequirementsQuality Controldesign product, engineer manufactureof product, engineer production system,produce products, manage engineeringworkflowproduct standards, tolerance standards,production requirements, designconstraints, external design constraints,evaluation guidelines, planningpolicies, quality functional deploymentmethods, evaluation knowledge,validation run requirements, validationrun results 1 Defense Support Center Philadelphia, formerly Defense Personnel Support Center, is a DLA organization. The organization is responsible for supplyingpatterns to government contractors. Product Datadesign product, engineer manufactureof product, engineer production system,produce productsproduct needs, market data, designprocess knowledge, design knowledge,design change requests, product model,physical models, products Process Dataengineer manufacture of product,engineer production system, produceproductsManufacturing features, processchange requests, manufacturingprocess knowledge, product realizationprocess model, process models, processspecifications, operations sheets,control programs, scheduling package,component catalogsProduction Facilitiesengineer production system, produceproductsfacility design, facility change requests,facility reports, facility implementationplans, manufacturing facility layout,information systems for plant layout,production system evaluation results,production systems library, plant orders Cost Estimationengineer production system, produceproductstime and cost reference data, time andcost constraints, cost reports,production cost estimates, facility costestimates Manufacturing Capability andResourcesengineer manufacture of product,engineer production system, produceproductstooling/materials, machinability data,resource descriptions, equipment/labor,materials knowledge, material stockdescriptions, equipment orders,tooling/materials orders, bill ofmaterials, equipment availability,resources available, resourcerequirements, tooling designsProduction Managementdesign product, engineer productionsystem, produce products, manageengineering workflowproduct orders, receiving reports,manufacturing calendar, customerorder status, product inventory,personnel actions, product inventory,production constraints, engineeringtask status, engineering assignments A set of exchange standards is needed to meet the requirements of industry if companies are to readily exchangeinformation about products and processes utilized in the product life cycle. There is a clear recognition in the standardscommunity that the process leading to standards is very slow. Through NIST’s SIMA program, the concept of an InitialManufacturing Exchange Specification (IMES) for manufacturing systems integration was introduced [23]. The IMESprovides a mechanism to develop interim fast-track specifications. The IMES is intended to be the result of modularstandards development and a precursor to, not a replacement of, the official standards development process. The IMES willfill an important void in the manufacturing systems integration process. Over the years NIST’s Manufacturing Systems Integration Division (MSID) has been working on developing specifications or IMESs for information-basedmanufacturing. The following lists MSID research results that are expected to contribute to the manufacturing systemsintegration effort. 1) Information Requirements for the Manufacturing Resource [24]. A requirements specification for the manufacturingresource is defined. The resource includes milling and turning machine tools, cutting tools suitable for the processes ofmilling, drilling, boring, reaming, tapping, turning, grooving, etc., and the tool assembly components required to mount thecutting tools to the machines. 2) Information Model for the Manufacturing Resource [25]. The model, in EXPRESS, is the manufacturing resource datamodel developed for the NIST Rapid Response Manufacturing Intramural Project. The model was developed based uponthe requirements specification described in item 1. 3) Activity Model for the Manufacturing Enterprise [22]. The activity model identifies the functions and interfaces requiredof manufacturing applications software systems. It describes the activities and information flows common to mostorganizations involved in the manufacture of electro-mechanical products. 4) Information Requirements for the Manufacturing Processes [26]. A list of requirements for specifying themanufacturing processes was identified. The requirements analysis was one of NIST’s Process Specification Languageproject efforts. 5) Information Requirements for the Shop Floor Status [27]. The requirements specification identifies the informationneeded for the exchange of information between shop floor scheduling and shop floor data collection applications. 6) Information Model for the Shop Floor Status [28]. An EXPRESS model describes shop floor status data. It supportsdata exchanging and sharing between shop floor scheduling and shop floor data collection applications. 7) Activity Model for the Engineer Production System [29]. The activity model identifies the functions involved inproduction system engineering and the data required to integrate engineering software applications. 8) Information Requirements for Discrete-Event Simulation [12]. The requirements specification identifies informationneeded for describing exchange data between discrete-event simulation models of manufacturing systems. 9) Information Requirements for the Plant Layout [10]. The requirement specification identifies information needed fordescribing exchange data between plant layout design and simulation systems for manufacturing systems. 10) Activity Model for the Machining Process Planning [30]. The activity model identifies functional components and datarequirements in the process planning systems. The model was developed for the automated machining process usingnumerical controllers. 11) Information Requirements for the Process Plan [11]. The requirements specification identifies information needed for ageneric process plan – workstation level. Such a specification would be used to integrate other planning and validationsoftware applications. 12) Information Model for the Process Plan [31]. An EXPRESS model describes a process plan within the NIST’sManufacturing Engineering Toolkit [32]. The model was developed based upon the requirements specification described initem 10. 8. CONCLUSIONThis paper describes a flow for designing and implementing a quality information model. This flow starts with choosingthe information modeling approach: ER, functional, or O-O. It proceeds to selecting the right combination of modelinglanguages. Once these tools for setting up the environment are chosen, the process of developing the model begins. Thisprocess includes defining the scope of applications, determining the information requirements, and writing down theconceptual data model using a formal data definition language. In implementing the information model itself, which is to be shared by different components of a manufacturing process orexchanged among CAD/CAM systems, it is necessary to determine if the data transfer is to be based on an in-memorystorage structure, disk files, or a database management system. To streamline the information model design andimplementation process, naming conventions and a glossary should be established. Different requirements of numericalprecision and measurement units should be included in the model to maintain system flexibility. Industrial review willgreatly enhance the system performance and user satisfaction. Finally, the paper identifies an example set of manufacturing data interfaces that could be modeled and standardized forsupporting manufacturing systems integration. REFERENCES:[1] Tsichritzis, D., and Klug, A., eds., “The ANSI/SPARC DBMS Framework Report of the Study Group on Databasemanagement Systems,” Infosystems, Vol. 3, 1978. [2] Chen, P. P., “The Entity-Relationship Model Towards a Unified View of Data,” ACM Transactions on databaseSystems, Vol. 1, No.1, March, 1976. [3] D. Appleton Company, Inc., “Integrated Information Support System: Information Modeling Manual, IDEF1 -Extended (IDEF1X),” ICAM Project Priority 6201, Subcontract #013-078846, USAF Prime Contract #F33615-80-C-5155,Wright-Patterson Air Force Base, Ohio, December, 1985. [4] ISO 10303-11:1994(E), Industrial Automation Systems and Integration Product Data Representation and Exchange -Part 11: The EXPRESS Language Reference Manual. [5] Schenck, D., and Wilson, P. “Information Modeling the EXPRESS Way,” Oxford University Press, New York, NY,1994. [6] http://www.rational.com/uml. [7] ISO 10303-1:1994, Industrial Automation Systems and Integration Product Data Representation and Exchange Part1: Overview and Fundamental Principles. [8] http://www.mel.nist.gov/msid/sima. [9] http://www.mel.nist.gov/namt. [10] Lee, Y. T., “Initial Manufacturing Exchange Specification (IMES): Requirements Analysis for the Plant LayoutApplication,” NISTIR 6139, National Institute of Standards and Technology, Gaithersburg, MD, July, 1998. [11] Ellis, K., Jones, A., and Lee, T., “Requirements Analysis: Process Plan Specification Workstation Level,” NISTIR6172, National Institute of Standards and Technology, Gaithersburg, MD, June, 1998. [12] Bartolotta, A., McLean, C., Lee, Y. T., and Jones, A., “Production Systems Engineering: Requirements Analysis forDiscrete-Event Simulation,” NISTIR 6154, National Institute of Standards and Technology, Gaithersburg, MD, April,1998. [13] Lee, Y. T., “Data Sharing Implementation Based on the Information Model for Apparel Pattern Making,” NISTIR5969, National Institute of Standards and Technology, Gaithersburg, MD, January, 1997. [14] Rumbaugh, J., Blaha, M., Premerlani, Eddy, F., and Lorensen, W., “Object-Oriented Modeling and Design,” Prentice-Hall, Inc., Englewood Cliffs, NJ, 1991. [15] Lee, Y. T., “Extensions of the Prototype Application Protocol of Ready-to-Wear Apparel Pattern Making,” NISTIR5727, National Institute of Standards and Technology, Gaithersburg, MD, October, 1995. [16] AutoCAD Release 11 Reference Manual, AutoDesk, Inc., August, 1990. [17] Efe, K., Delcambre, L., Steward, A., and Remedios, I., “Evaluation of Neutral Data Formats for the Representation of2-D pattern Pieces,” USL A-CIM Technical Report #2, University of Southwestern Louisiana, LA, February, 1990. [18] Read, M. E., “Apparel Manufacturing Glossary for Application Protocol Development,” NISTIR 5572, NationalInstitute of Standards and Technology, Gaithersburg, MD, February, 1995. [19] Pawlak, C. G., “A Survey of Standards for the U.S. Fiber/Textile/Apparel Industry,” NISTIR 5823, National Instituteof Standards and Technology, Gaithersburg, MD, April, 1996. [20] Lee, Y. T., “A Bibliography on Apparel Sizing and Related Issues,” NISTIR 5365, National Institute of Standards andTechnology, Gaithersburg, MD, February, 1994. [21] Lee, Y. T., “Body Dimensions for Apparel,” NISTIR 5411, National Institute of Standards and Technology,Gaithersburg, MD, April, 1994. [22] Barkmeyer, E. J., Editor, “SIMA Reference Architecture Part 1: Activity Models,” NISTIR 5939, National Institute ofStandards and Technology, Gaithersburg, MD, December, 1996. [23] Kemmerer, S., and Fowler, J., Editors, “Initial Manufacturing Exchange Specification (IMES),” NISTIR 5978,National Institute of Standards and Technology, Gaithersburg, MD, February, 1997. [24] Jurrens, K., Fowler, J., and Algeo, M. B., “Modeling of Manufacturing Resource Information, RequirementsSpecification,” NISTIR 5707, National Institute of Standards and Technology, Gaithersburg, MD, 1995. [25] http://www.mel.nist.gov/rrm/fy97/jul97mrmodel.exp. [26] Schlenoff, C., Knutilla, A., and Ray, S., “Requirements for Modeling Manufacturing Process: A New Perspective,”Proceedings of Design Engineering Conferences, Sacremento, CA, September, 1997. [27] Lecapitaine, C., Riddick, F., and Jones, A., “IMES II – Production Management Standards: Requirements Analsysisfor Shop Floor Status,” NISTIR 6123, National Institute of Standards and Technology, Gaithersburg, MD, 1998.. [28] Riddick, F., and Loureau, A. M., “Models for Integrating Scheduling and Shop Floor Data Collection,” Proceedings ofthe 16 IASTED International Conference, Innsbruck, Austria, February 17-19, 1997. [29] McLean, C., and Leong, S., “Industrial Need: Production System Engineering Integration Standards,” NISTIR 6019,National Institute of Standards and Technology, Gaithersburg, MD, May, 1997. [30] Feng, S. C., “A Machining Process Planning Activity Model for Systems Integration,” NISTIR 5808, National Instituteof Standards and Technology, Gaithersburg, MD, March, 1996. [31] Lee, Y. T., “Initial Manufacturing Exchange Specification (IMES): Information Model for the Process Plan -Workstation Level,” NISTIR 6307, National Institute of Standards and Technology, Gaithersburg, MD, March, 1999. [32] Iuliano, M., “Overview of the Manufacturing Engineering Toolkit Prototype,” NISTIR 5730, National Institute ofStandards and Technology, Gaithersburg, MD, October, 1995.